Exports are easy to store and surprisingly difficult to trust. The same day can appear in several files, older entries can be edited, and a new export can contain mostly familiar data with a handful of meaningful corrections. I built TimeTrackDB to preserve that uncertainty instead of flattening it away.

The system follows a Bronze and Silver architecture. Bronze records immutable source metadata, fingerprints, and versions; Silver publishes the current reconciled event truth while retaining history. Generic event rows support timestamps, durations, schema versions, and event-specific JSON data, allowing the same foundation to represent more than one kind of event.

Adapters define source formats, field mappings, validation rules, owned views, and optional custom handlers. That means a new data source can reuse the ingestion, auditing, history, and rollback machinery rather than growing a parallel ETL pipeline. Time tracking is the first deep use case, not the limit of the architecture.

Operational behavior is part of the data model. Imports can be quarantined when their proposed change set looks unsafe, every ETL stage records durable audit milestones, and operators can reconstruct or restore earlier states. TimeTrackDB is designed to answer not only “what is true now?” but also “what arrived, what changed, and how can I safely go back?”