Verifying the Chain and Reading Gaps

A chain is only useful if it is checked. Verification walks the entries, recomputes the hashes and confirms they still agree.

Where to find it

Architect Panel → Activity:

Audit Chain — the head, last verified time, state and message for each datastore
Activity Log — the entries themselves
Error Log — where a failed verification run is likely to surface

What the chain head records

Datastore — which chain this is.
Head sequence and head hash — the current end of the chain.
Last sealed — when the head was last advanced.
Last verified — when it was last checked.
Verify state and message — the result, and what it was.

Reading the state

A good state means the entries recomputed to the hashes they carry, and the head matches. That is a positive statement about the whole history, not just the recent part.

A failure means the recomputation disagreed somewhere. The message identifies where, which is the starting point for everything that follows.

Check last-verified, not just the state

A chain showing a good state but last verified eight months ago is telling you about the world as it was in December. The state and the date have to be read together — this is the single most common misreading of the screen.

Gaps

Detected gaps are recorded rather than glossed over. A gap means the sequence skips, which is what deletion looks like from inside the chain.

Not every gap is sinister — a restore from backup that replayed part of a table, or a maintenance operation done outside the application, can produce one. But every gap needs an explanation that somebody wrote down at the time, because an unexplained gap is indistinguishable from a covered track.

When verification fails

Do not correct anything. Repairing the chain destroys the evidence of what happened to it.
Record the state, the message and the timestamp as you found them.
Establish what has direct database access, and check whether a restore, migration or manual operation happened around that sequence.
Escalate — a genuine chain failure is a security incident, not a maintenance task.

The instinct to tidy it up is strong and it is exactly wrong. A broken chain that has been repaired tells you nothing at all.

Verify on a schedule

Regular verification narrows the window in which a problem could have arisen. Verified monthly, a failure is localised to a month; verified once a year, it is localised to a year — and a year is usually long enough that nobody can reconstruct what happened.

Operations outside the application break chains

This is the practical warning. A bulk update run directly against the database, a partial restore, a data migration executed in SQL — all legitimate operations, all capable of breaking a chain.

Plan for it: do such work through the application where possible, and where it is not, record what you did and when, so the resulting gap has a contemporaneous explanation rather than a reconstructed one.

Worked example

A monthly verification returns a failure on one datastore. Nothing is touched. The message points at a sequence range matching a weekend when a partial restore was performed after a storage incident, and the change record for that work confirms it. The explanation is attached to the incident record, verification is re-run to establish a new clean baseline, and the event is closed as understood rather than as unexplained.

Recommendations

Verify monthly and read the last-verified date, not only the state.
Never repair a broken chain.
Document any operation done outside the application, at the time.
Treat an unexplained gap as an incident until it is explained.