FTB-C000731 / Implementation concept

Bitemporal data

Bitemporal data models both when a fact applies in the business domain and when it is known to the recording system.

Also known asbitemporal ledger

Advanced 3 linked topicsEvidence-reviewed

Definitions

In plain terms

A late correction can change today's understanding of yesterday while preserving what an earlier observer could have known.

Technical

D30 separates business-effective time from per-version recorded_at; knowledge-cutoff exports select complete correction groups by group.available_at and independent retained heads.

Scope

A source clock or application timestamp is not automatically a physical database COMMIT timestamp.

Examples

  • A synthetic correction effective on Monday but available on Wednesday is absent from Tuesday's knowledge snapshot.

Common misconceptions

  • Using only the business date cannot answer what was known at an earlier cutoff.

Concept relationships

Prerequisites

Related

Where this concept is used

Evidence and governance

  1. Bitemporal Tables MariaDB · official platform documentation

    Supports: preferred label, short definition, variant distinction

    Limits: D30 explicit knowledge/availability fields do not inherit MariaDB system-versioning or physical commit timestamps.

  2. D30 glossary teaching-profile scope, Batch 013 The Fintech Builder · internal governed contract

    Supports: technical definition

    Limits: No independent regulatory mandate, real-bank dataset, service execution, external witness or production assurance is claimed.

Reviewed by
fintech-builder-batch-013
Last reviewed
2026-10-27
Next review
2027-10-27
Record status
evidence reviewed

This record is evidence-reviewed and readable, but not yet promoted to published — it is served noindex,follow and excluded from the sitemap.

Written by

Fintech engineer building market-data and financial systems, and the author of every article, glossary record, and reference implementation on The Fintech Builder.