Market data gets revised. GDP is restated, fundamentals are corrected, tickers change hands. TemporalDB is designed to keep every captured response and every revision, so a backtest sees only what was knowable on its date and any result can be replayed later from the same inputs.
Most tools collapse these into a single as_of date, which is how lookahead bias sneaks into backtests. TemporalDB keeps them apart and makes you say which one you mean.
When does this fact apply? The quarter a GDP figure measures, the date a price traded.
When was this version publicly available, according to evidence such as an ALFRED vintage date?
When did our system actually receive and accept this version?
Which physical inputs did this particular execution read?
Queries carry explicit context fields: mode, effective_at or a date range, known_at, and knowledge_basis set to local_received or provider_published.
Pick a dataset, slide known_at, and switch the knowledge basis. The demo applies the design’s rules to a small illustrative history. Values and dates are made up for the demo.
The three layers are about trust, not temperature: Bronze does not mean cold storage and Gold does not mean hot.
Each captured response is stored as an immutable payload plus a capture record: provider, endpoint, sanitised request, timing, HTTP status, content hash, adapter version and outcome. Credentials are never stored.
Normalised assertions with stable keys and immutable revision identity: effective interval, provider vintage and its evidence, local receipt, status and a link to whatever it supersedes.
The latest cleaned projection over Silver, built from versioned validation, identity and source-precedence rules. History queries use Silver, never today’s Gold pretending to be the past.
If capture fails, TemporalDB serves the last captured value with a stale warning, or fails if there is none. A crash between steps must never leave a success record pointing at missing bytes.
The same contracts run on a laptop and on a lab cluster. Switch the view to see what changes.
Queries live in a shared library with immutable revisions. Widgets bind to a query and revision by default; following the latest revision is an explicit choice. Refresh creates a new execution and never edits the old receipt.
TemporalDB plugs into BDOBB’s existing table execution path as a new source. Derived tables, pivots, charts and exports carry the parent receipt, so a derived widget cannot quietly query newer data while showing the old receipt.
All screenshots: Data Workbench interactive concept, 27 Sep 2026, synthetic data, no live connections.
Keeping a snapshot number or an output file is not enough to replay a result. A protected audit or backtest run keeps everything it depended on.
Input snapshots, raw evidence, query revisions, cleaning and projection artefacts, runnable environments and result evidence, indefinitely.
Expiry names explicit snapshot IDs after checking every dependency. Broad age-based expiry is not allowed on protected catalogs. DuckLake supports dry runs and explicit version lists; TemporalDB adds its own dependency checks first.
PostgreSQL catalogs, control records and the object data they reference are backed up together, and protected replay is verified after restoring to a separate environment.
Each stage lands reviewable work. TemporalDB is complete only when all seven pass.
| # | Deliverable | Acceptance gate | Status |
|---|---|---|---|
| 1 | Inventory and canonical time, identity and query contracts | Actual branches, deployed services, data volumes and coverage recorded; compatibility mappings resolved | Planned |
| 2 | PostgreSQL control service, DuckLake adapters, capture and recovery | Multiple workers, capture-failure fallback, crash recovery, no duplicates, catalog and object restore | Planned |
| 3 | Daily prices, fundamentals, identities and FRED vintage pipelines | Both knowledge policies, correction examples, lineage; unknown publication history cannot leak into strict queries | Planned |
| 4 | Tick-vault migration and acquisition integration | Pinned replay, cancellation, resumability, reference joins and NAS load measurements | Planned |
| 5 | Shared query library and execution API | Two BDOBB clients, revision conflicts, two API instances, worker loss, paging and permissions | Planned |
| 6 | Query data widgets and linked presentation | Existing table, pivot and chart execution reused; parent receipt survives derivation, refresh and export | Planned |
| 7 | Protected audit runs and migration cutover | Concurrent cleanup cannot break a protected run; restored replay works; legacy limits stay visible | Planned |