Registry integrity

Every registry row contains the cryptographic digest of the previous one. The result is a chain: modifying, inserting or deleting a row makes every later row inconsistent, and the check reports exactly where the break is.

How it works

When a row is written, the system computes a SHA-256 digest over canonical content comprising:

the digest of the previous row of the same organisation (the first row anchors to an initial value tied to the organisation code);
the exact moment in canonical form;
type, case, author, description and references.

row 1:  hash₁ = H( "genesis:ORG-…" ‖ ts₁ ‖ type₁ ‖ case₁ ‖ author₁ ‖ text₁ ‖ meta₁ )
row 2:  hash₂ = H( hash₁           ‖ ts₂ ‖ type₂ ‖ case₂ ‖ author₂ ‖ text₂ ‖ meta₂ )
row 3:  hash₃ = H( hash₂           ‖ …                                            )

The short identifier shown in the interface (eight characters) is the prefix of the row's digest: convenient to quote in a message and unambiguous about which row it means.

Chains are per organisation: your sequence is independent of anyone else's, and no other organisation's data enters the computation.

The check

The registry page shows the result of the check: how many rows were verified and the overall outcome. The check recomputes the whole chain and compares every digest with the stored one.

Chain intactEvery row verifies. The registry can be produced as evidence without reservation.

Chain brokenThe first inconsistent row is reported: from there on the sequence is no longer verifiable. The rows before it remain valid.

If the chain is broken

This is not something to ignore, nor to «fix» yourself. There are few possible causes and they must be told apart before acting.

Export the full CSV immediately, with no filters: it carries the digests and freezes the current state as evidence.
Change nothing in the registry and do not attempt to rebuild rows.
Open a support request under «Technical problem», quoting the number of the first inconsistent row and attaching the CSV.
Note the event in your own security records: if somebody tampered with the data, the discovery and the response are themselves facts to document.

Typical causes, in order of frequency: a partial restore from a misaligned backup; a manual intervention on the database; an interrupted migration. A hostile alteration is rare, but it is precisely what the mechanism exists to make visible.

What it proves (and what it does not)

It provesThat the sequence of rows has not been altered after the fact, and that an export handed to a third party matches the recorded sequence.

It does not proveThat the content of a row was true when written. The chain guarantees integrity, not veracity: that remains the responsibility of whoever performs the act.

This is not a timestamp certified by a third party: it is internal evidence of non-alteration. If your context requires a qualified timestamp, apply it to the periodic export of the registry, which is a self-contained file.

Having a third party verify the export

The CSV carries, for each row, the fields that enter the computation plus hash and prev_hash. A consultant or an expert witness can recompute the chain independently: start from the initial value tied to the organisation code, concatenate the fields in the documented order, and check that every digest matches. No access to our systems is needed.