Does a hash chain prove that data was correct from the start?

No. It only proves that data has not been unnoticeably altered since the chain began — an observation that was wrong from the outset remains unaffected by this.

What is the difference between event time and recording time?

Event time is when something actually happened in reality; recording time is when it was recorded in the system. With offline capture, the two can differ significantly.

← Knowledge

Bitemporal Event Store: How an Immutable History Works

A bitemporal event store records every observation as an immutable, timestamped event (append-only) and distinguishes two time axes: when something happened in reality, and when it was recorded in the system. An additional hash chain makes subsequent tampering detectable — but only from the point at which the chain began, not retroactively for the period before that.

Storage principle: Append-only (never delete, never overwrite)
Time axes: 2 (event time + recording time)
Integrity mechanism: Hash chain
External anchoring: OpenTimestamps (daily) + RFC 3161 timestamps (weekly)

What "append-only" and "bitemporal" mean

Append-only means: an event, once written, is never deleted or altered — a correction is appended as a new, independent event that references the original one. Bitemporal means: every event carries two timestamps — when it actually happened in reality (event time) and when it was actually recorded in the system (recording time). This separation makes it visible when an observation was entered late (for example, offline capture in the field that is only synchronised later), without distorting the actual observation time.

What the hash chain proves — and what it does not

Every new event contains the hash value of its predecessor. A subsequent change to an earlier event would visibly break this chain. Crucially, though, this mechanism proves integrity only from the point at which the chain actually started running. For events that predate the start of the chain, there is no retroactive cryptographic guarantee — a chain calculated retroactively proves nothing about the past before its own starting point.

External anchoring

To protect the chain itself against later tampering, it is additionally anchored externally: daily via the free OpenTimestamps protocol and weekly via an RFC 3161-compliant timestamping service. This shifts trust from an internal claim to an externally verifiable point in time.

For your business

In practice, this means: an observation captured in the field without a network connection, and only synchronised hours later, retains its actual observation time — it is not incorrectly dated to the later synchronisation time.

For the commissioning authority

An append-only history is a strong, but not an absolute, argument for traceability — it does not replace an independent assessment of the actual evidentiary value in a specific case.

What this does not mean

The term "court-proof" is deliberately not part of our communication (Art. 13a UWG) — a court always freely assesses evidence (Art. 157 ZPO); technical safeguards can support that assessment but cannot replace it.
The hash chain proves integrity only FROM the start of the chain onward, never retroactively for data preceding it — this is a deliberate, honest limitation of the technology, not a marketing claim.
A bitemporal event store protects against an unnoticed subsequent change, not against an initial observation that was wrong from the outset.

Frequently asked questions

Does a hash chain prove that data was correct from the start?: No. It only proves that data has not been unnoticeably altered since the chain began — an observation that was wrong from the outset remains unaffected by this.
What is the difference between event time and recording time?: Event time is when something actually happened in reality; recording time is when it was recorded in the system. With offline capture, the two can differ significantly.