Why I Built
Tamper-Evident Telemetry
If operational history matters, silent edits should be hard to ignore.
Telemetry is often treated as disposable. It helps during a live run, then fades into storage until retention deletes it. But some operational history has a different role. It explains what happened, when it happened, and what evidence a team used to make decisions.
If that history can be changed quietly, it becomes less useful as evidence. A dashboard may still look clean, but the team has lost confidence that the story is complete.
The point is not perfect security
Tamper-evident telemetry is not the same as making data impossible to modify. The goal is more practical: make unexpected changes visible. If an event disappears, changes order, or no longer matches the surrounding history, the system should make that easier to detect.
Operational history has value
During incidents, audits, handoffs, and customer conversations, the timeline matters. People need to know whether a job started, what it skipped, which warnings appeared, and what final state was reported. That history should be treated as more than a temporary UI artefact.
Trust should not rely on screenshots
Without a durable trail, teams often fall back to screenshots, copied log lines, and memory. Those are weak foundations for understanding production behaviour. A tamper-evident event stream gives the team a better source of truth.
Small mechanisms, better confidence
OpenTrace uses an append-only mindset because operational facts should accumulate rather than constantly overwrite one another. Tamper evidence extends that idea: the system should help preserve confidence in the sequence of events, not just display the latest status.