Help Center / Timeline integrity
Timeline integrity
Your append-only timeline is the defensibility artifact auditors and cyber-insurers ask for. Klaxon seals it with a tamper-evident SHA-256 hash chain so any alteration of a past event becomes visibly detectable.
Why a hash chain
The timeline records, in order, everything that happened: when the incident was declared, when facts changed, when tasks were worked, when evidence was attached, when notices went out. To be trustworthy after the fact, it must be append-only and provably so. Klaxon doesn't merely discourage editing — it makes editing evident.
How the chain works
- Each timeline event has immutable fields: its id, type, body, and timestamp.
- When the incident is rendered, Klaxon computes a SHA-256 hash for each event that covers the event's own fields plus the previous event's hash. The first event chains from a fixed genesis value.
- This links every event to the one before it. The newest event's hash is the "head" of the chain.
- Sealing is append-only: once an event has a stored hash, Klaxon never rewrites it. New events get sealed as they're added.
- On every render, Klaxon re-verifies the chain. If any past event's stored hash no longer matches a freshly computed hash, the chain is broken from that point on, and Klaxon records the index of the first break.
Because each hash depends on the one before it, altering or deleting any single past event breaks every hash after it — you can't quietly edit history without it showing.
The verified vs tampered badge
Next to the incident ID, a badge reports the chain's status:
| Badge | Meaning |
|---|---|
| timeline verified | The hash chain is intact end to end. Hover to see the chain head (first 16 hex characters). |
| TIMELINE TAMPERED | A past timeline entry was altered or removed — the chain broke. Hover to see which event index the break started at. |
| (no badge) | Not yet sealed — e.g. a brand-new incident before its first events render. |
It's all local
The chain is computed and checked in your browser (using the browser's built-in SHA-256). Nothing about the timeline — bodies, hashes, or anything else — leaves the machine to make this work. It is part of the zero-network core.
Integrity in the exports
The auditor bundle JSON includes a timeline_integrity field carrying the verification result (ok / broken, the break index if any, the chain head, and when it was checked), so an auditor or carrier can see the integrity status alongside the timeline itself.
If you see "TIMELINE TAMPERED"
This means a stored event no longer matches its computed hash — the data backing this incident in localStorage was modified outside the normal append-only flow (for example, edited directly in browser storage, or partially corrupted). What to do:
- Stop and preserve the current state — don't keep editing.
- If you have a prior auditor bundle export, compare its timeline to the current one to find what changed.
- Treat the export taken before the break as the authoritative record; document the discrepancy.
- For audit/insurance purposes, the broken badge is itself meaningful evidence — it tells you precisely from which event integrity can no longer be vouched for.
See also the FAQ entry on the tampered badge.