Working AtlasIntegrity & forensics

Ledger Chain Autopsy

Edit, delete, or reorder a synthetic event, find the first broken link, then see what a local rewrite can hide.

TryEdit one event, rewrite the local chain, then compare its head with the saved checkpoint.

Watch forRewritten local links validate, but the separate checkpoint still catches the changed synthetic chain.

Jump to the model

Separate teaching model

The linked story describes related work; the scenarios and results here are synthetic.

Interactive model

Change the example ledger

Tampering scenario

The checkpoint represents a head hash copied away before the example changes. A hash stored only beside the events would share their writer and could be replaced too.

Synthetic events use browser Web Crypto SHA-256. This example does not connect to the Agent Activity Ledger or test a deployed system.

SYNTHETIC EVENT CHAIN

Follow the links, find the break

Local verification

Computing…

Every sequence, predecessor link, and event hash agrees.

External head checkpoint

Checking…

An earlier head copied outside this event store.

A hash chain can make edits detectable when a trusted earlier head is available; it cannot stop someone with write access from rewriting the entire local history. Sequence numbers here illustrate ordering. The source project documents a monotonic sequence for insertion order, but this lab does not reproduce its storage or concurrency behavior.

Preparing the interactive experiment…

Skill practicedReason about integrity, ordering, and threat-model limits

Connection to my workMy public Agent Activity Ledger contribution includes hash-chained verification; this toy model uses synthetic events and limited guarantees.

Understand the result

Four fixed example events are serialized with stable field order, linked to the previous SHA-256 digest, and checked in sequence. Change one field, remove a record, or reorder records to inspect the first mismatch. “Rewrite the local chain” recalculates hashes after the edit so you can compare a locally valid chain with a previously saved head. Events, times, and outcomes are synthetic.

Controls

Tampering scenario: Choose an unchanged example, a field edit, deletion, reordering, or a writer recomputing the local chain.
Compare exported checkpoint: Compare the current head with a fixed digest copied outside the example ledger before changes.
Restore original chain: Rebuild the four synthetic events and their original hashes.

What to watch for

Edit one event. Its stored hash no longer matches the event, and the next event still points to the previous recorded digest.
Delete or reorder records. The sequence and predecessor links reveal where the event order first diverges.
Rewrite the local chain. The recomputed links are internally consistent, but the new head no longer matches the saved checkpoint.
Turn off the checkpoint comparison. A writer who can replace all data in one local store can replace its chain and its local head together.

Why it happens

Each event digest covers a stable serialization of that event plus the previous digest. A changed event alters its digest and breaks the following link. A trusted copy of an earlier head adds a separate comparison point. Hash chaining makes changes detectable when that independent reference is available; it does not prevent a writer with full store access from rebuilding a different valid history. This model omits database transactions, concurrent writers, authentication, durable storage, and checkpoint delivery.

How this idea relates to the linked work

My public Agent Activity Ledger contribution includes its initial hash-chained ingestion and verification MVP. The project records canonical JSON and SHA-256 links, and documents a monotonic sequence fix for ordering rapid inserts. This small browser model uses synthetic events to explain those ideas; it does not reproduce the repository, its storage, or its concurrency behavior.

See the broader engineering brief