TimeTrackDB: A Local-First Warehouse for Events That Change

When the same export tells a different story

Yesterday’s export and today’s may cover the same months but disagree about a handful of events. Older entries change; files overlap. TimeTrackDB preserves what arrived and reconciles those differences, so storing an export does not mean blindly trusting it.

Concept illustration for timetrackdb; not a product screenshot.

Separate immutable arrivals from current truth

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.

From arrival to current truth

Bronze preserves the arrival. Validation and reconciliation decide what can become current Silver data.

flowchart TD
    Export[Source export] --> Bronze[Immutable arrival evidence]
    Bronze --> Check[Validate and reconcile]
    Check -->|Accepted| Silver[Current events and history]
    Check -->|Unsafe| Quarantine[Quarantine for inspection]

Operational trust belongs in the model

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?”